User-Device-Implemented Contest with Alert Feature

ABSTRACT

Provided, inter alia, is a type of contest in which, at various intervals, geographically dispersed players attempt to answer the identical problem at substantially the same time. In representative embodiments, problems (typically, questions) are made available at seemingly random times throughout the day (or throughout some specified time interval), and players have the opportunity either to respond to the problem or (e.g., in the event that a given player is occupied when a particular problem arises) to pass on the current problem and wait for another one. In such embodiments, more questions are made available than the players are permitted to answer in accordance with the rules of the game, so that players have flexibility as to when they participate.

This application is a continuation of U.S. patent application Ser. No.11/539,179, filed Oct. 6, 2006, which in turn claims the benefit of U.S.Provisional Patent Application Ser. No. 60/724,473, filed on Oct. 6,2005, and titled “Real-Time Incentivized Game Platform”, whichapplications are incorporated by reference herein as though set forthherein in full.

FIELD OF THE INVENTION

The present invention pertains to a contest that is played substantiallysimultaneously by a number of players.

BACKGROUND

A variety of different kinds of games and contests exist. However,people constantly are looking for new ways in which to compete withothers.

SUMMARY OF THE INVENTION

The present invention addresses this need by providing, inter alia, anentirely new type of contest in which, at various intervals,geographically dispersed players attempt to answer the identical problemat substantially the same time. In representative embodiments, problems(typically, questions) are made available at seemingly random timesthroughout the day (or throughout some specified time interval), andplayers have the opportunity either to respond to the problem or (e.g.,in the event that a given player is occupied when a particular problemarises) to pass on the current problem and wait for another one. In suchembodiments, more questions are made available than the players arepermitted to answer in accordance with the rules of the game, so thatplayers have flexibility as to when they participate.

Thus, in one aspect the invention is directed to systems, methods andtechniques for implementing a simultaneous, but intermittently played,contest. Initially, a problem is delivered substantially simultaneouslyto geographically dispersed players, the problem being identical for allplayers. Responses to the problem are received from the players, thecorresponding response times are measured, and scores are determined forthe players based on the responses and corresponding response times. Theforegoing steps are then repeated a plurality of times, with a mediantime interval between delivery of consecutive problems being at least 30minutes, and with an aggregate score being maintained for each of theplayers.

The foregoing summary is intended merely to provide a brief descriptionof the general nature of the invention. A more complete understanding ofthe invention can be obtained by referring to the claims and thefollowing detailed description of the preferred embodiments inconnection with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an overview of an alert system according to arepresentative embodiment of the present invention.

FIG. 2 illustrates communication between a user device and a serveraccording to a representative embodiment of the present invention.

FIG. 3 is a block diagram showing some of the components of a userdevice according to a representative embodiment of the presentinvention.

FIG. 4 illustrates an example of alert information and timesynchronization information according to a representative embodiment ofthe present invention.

FIG. 5 is a flow diagram illustrating an overview of a process forimplementing an alert system according to a representative embodiment ofthe present invention.

FIG. 6 is a flow diagram illustrating a process for conducting a contestaccording to a representative embodiment of the present invention.

FIG. 7 illustrates an initial user interface questioning whether aplayer wants to participate in the current problem in a contestaccording to a representative embodiment of the present invention.

FIG. 8 illustrates a user interface for presenting a problem andaccepting a response to it in a contest according to a representativeembodiment of the present invention.

FIG. 9 illustrates a sliding scale for conversion of game points to Dotzaccording to a representative embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

This application is related to commonly assigned U.S. patent applicationSer. No. 11/539,180, filed Oct. 5, 2006 and titled, “System ForSubstantially Simultaneous Alerts”, now U.S. Pat. No. 7,805,151. Thatapplication is incorporated by reference herein as though set forthherein in full.

The present disclosure is divided into sections. The first sectiondescribes certain technological considerations for implementing contestsand other methods of the present invention. The second section describesan exemplary contest that may be implemented using such platforms.Subsequent sections provide additional information, as indicated bytheir headings.

Substantially Simultaneous Alert Technology.

Many of the techniques of the present invention require that a messagebe delivered substantially simultaneously to a large number ofgeographically dispersed (e.g., spread across different cities, statesor even countries) individuals or devices. FIG. 1 illustrates anoverview of an alert system 10 for achieving this goal, according to arepresentative embodiment of the present invention.

Generally speaking, a central server 12 drives the alert system 10,communicating with a plurality of different user devices (e.g., devices21-26). Each such device 21-26 typically has a user associated with it(e.g., user 31 for device 21 and user 32 for device 22). In some cases,a single user (e.g., user 33) has two or more user devices (e.g.,devices 23 and 24) that are registered with server 12, as discussed inmore detail below.

Server 12 may be implemented as a single physical device, but morecommonly will be implemented as a server cluster, with redundancy,appropriate load-sharing hardware and software, and differentfunctionality distributed across different physical boxes, as is wellknown in the art. In one embodiment, different physical devices are usedfor communicating across different kinds of networks (e.g., directlyover the Internet, by SMS messaging, or using a proprietary wirelessprotocol).

It is noted that although only six user devices 21-26 are illustrated inFIG. 1, this is for ease of illustration only. Typically, there will bemany more user devices that participate in the alert system 10, such asmore than 50, 100, 500, 1,000 or even 10,000 such devices (as well as asimilar number of users). Also, the same server 12 can be used to handlemultiple alert systems, e.g., using different distribution lists anddifferent back-and processing routines for such different systems.

Each user 31-35 preferably has pre-registered with server 12 for thecurrent alert system 10, designating the device(s) on which such user31-35 will be receiving the alerts, as well as the manner in whichserver 12 is to communicate with such device. In this latter regard, thepresent invention contemplates multiple different modes of communicationbetween server 12 and the various user devices 21-26.

The most commonly anticipated communication mode will involve the use ofa wireless network 41, so that the corresponding user device 21 will bemore likely to be able to communicate with server 12 at any time of day.However, as discussed in more detail below, the preferred embodiments ofthe present invention do not require real-time communication in order tofunction as intended.

A variety of different specific communication techniques may beimplemented over a wireless network 41. For instance, messages may besent via short messaging service (SMS), using wireless Webcommunications, or using any of the other wireless data protocols(whether public or proprietary) that are supported by the particularwireless carrier.

Another commonly anticipated communication mode involves direct Internetcommunications 42. This general mode also can be used to conveyinformation using any of a variety of different specific protocols, suchas hypertext transfer protocol (HTTP), file transfer protocol (FTP), anyproprietary data-transfer protocol, or even instant messaging or e-mailmessaging protocols.

As noted above, in certain cases a single user 33 will register multipledifferent devices 23 and 24 with server 12 for participation in aparticular alert system 10. Moreover, as shown in FIG. 1, multipledifferent communication paths 43 may be used for the different devices23 and 24 (e.g., a wireless network for device 23 and a direct Internetconnection for device 24).

The user 33 preferably has the ability to designate multiple devices 23and 24 as both being currently active, so that when the alert occurs itwill be delivered by both devices, thereby maximizing the likelihoodthat the user 33 will be in the vicinity of one of such devices 23 and24 at the appropriate time. Alternatively, the user 33 preferably alsohas the ability to designate only a single one of the devices 23 and 24to deliver the message, e.g., depending on when the message is to bedelivered. In such a case, the user 33 preferably defines a schedule,indicating which device 23 and 24 is active at which times. In addition,more than two devices 23 and 24 may be registered, and the user 33preferably can designate any number as being active at a given time.

Still further, it also is possible for server 12 to communicate with anon-networked device 25 (operated by user 34), e.g., by using a directconnection 44. Examples include transferring the required data using apoint-to-point cable, wireless connection (e.g., infrared or Bluetooth)or cradle. It is noted that such direct delivery 44 generally willconstitute only one of the steps in the overall delivery process, suchas where server 12 downloads the required information to a networkedcomputer or other device which, in turn, directly transfers it to userdevice 25.

Finally, server 12 may communicate with a user device 26 via a broadcastmedium (a wireless broadcast, e.g., using radio frequencies, and/or ahardwired broadcast, e.g., using television cable or Internetbroadcasts). In the illustrated embodiment, the user device 26 is aninteractive television, but any other kind of device instead may be usedfor receiving such broadcasts, including a general-purpose computer or acellular telephone.

The specific ways described above for server 12 to communicate with thevarious user devices 21-26 should be understood as being exemplary only.Any other communication modes or paths instead, or in addition, may beused. Also, any combination of different paths or modes may be used.

FIG. 1 illustrates one-way communication between the server 12 and thevarious user devices 21-26. However, in certain preferred embodiments ofthe invention, communication is bidirectional between server 12 and userdevices 21-26.

This is illustrated in FIG. 2, which shows an exemplary user device 21in communication with server 12. As discussed in more detail below, insuch embodiments server 12 typically communicates alert information 61and time synchronization information 62 to user device 21, and userdevice 21 typically communicates a response 63 to such alert information61 back to server 12. According to the preferred embodiments of theinvention, such communications can occur over significant time intervalsand often will vary significantly from one user device 21 to another ofthe user devices 22-26. Such variations often will be common even whereall of the user devices 21-26 are delivering the message 61 atsubstantially the same time and allowing the corresponding users 31-35to submit their responses 63 at substantially the same times. Morespecifically, in the preferred embodiments the alert information 61 maybe stored on user device 21 at any time prior to the scheduled deliveryand the response may be transmitted back to server 12 at any time afterit has been submitted by the corresponding user 31. In addition, thevarious types of information may be transmitted using differentcommunication channels.

FIG. 3 is a block diagram showing certain portions of an exemplary userdevice 21 according to a representative embodiment of the presentinvention. In the present embodiment, user device 21 has installed on itan alert-based client application 80 that performs all or nearly all ofthe special functionality associated with the present invention.Preferably, application 80 is implemented entirely in software (e.g., asa Java midlet or Brew application), but instead may be implemented inany of the other ways discussed herein.

As shown, application 80 communicates with the input/output interface 82of the device 21. Depending upon the particular device 21, interface 82generally will be comprised of hardware and software components forcommunicating, e.g., across a TCP/IP (Transmission ControlProtocol/Internet Protocol) network and/or across a wirelesscommunications channel (e.g., cellular-based, any of the 802.11x familyof protocols, Bluetooth, infrared, or the like). Generally speaking,input/output interface 82 provides the primary communication linkbetween client application 80 within device 21 and server 12.

As discussed in more detail below, application 80 stores certaininformation that it receives via interface 82 into device memory orstorage 83 (preferably non-volatile) until an appropriate time, such asthe designated delivery time. Application 80 preferably also monitorsdevice clock 85 and real-time clock 86. In this regard, device clock 85typically is a hardware device that provides timing clock signals forsynchronous processing by the various hardware components of device 21(e.g., including a general-purpose processor executing application 80).On the other hand, real-time clock 86 typically is implemented as asoftware application and provides the actual time of day, e.g., forreference by the corresponding user 31 and for time-stamping certaindata items within device 21.

FIG. 4 illustrates one example of a packet 90 containing alertinformation 61 and time synchronization information 62 according to arepresentative embodiment of the present invention. In the presentexample, synchronization information 62 includes a single timestampreflecting the current time maintained by server 12 (here, stated to thenearest 0.01 second). The alert information 61 includes a number ofentries 91-93, each having a corresponding delivery time 95 and message96. Although three such entries 91-93 are illustrated, any other numberinstead may be transmitted at a single time. In addition, although thesynchronization information 62 is illustrated as being transmitted inthe same packet 90 as the alert information 61, they instead can betransmitted in separate packets. Furthermore, in the present example themessages 96 are questions; however, as discussed in more detail below,any of a variety of different types of messages instead may be included.

FIG. 5 is a flow diagram illustrating an overview of a process forimplementing an alert system according to a representative embodiment ofthe present invention. This process preferably is implemented entirelyin software (with step 100 typically being performed by server 12 andthe other steps typically being performed by client application 80), butinstead may be implemented in any of the other ways discussed herein.Also, the process generally is discussed in the context of the hardwareconfigurations shown in FIGS. 1-3. However, it should be understood thatsuch references are for convenience and ease of understanding only andtherefore are merely exemplary in nature.

Initially, in step 100 the server 12 transmits alert information 61 andtime synchronization information 62 to a plurality of user devices21-26. Preferably, at least the alert information 61 is transmitted inan encrypted format, in order to prevent early discovery by the eventualrecipients 31-35. Currently, the preferred encryption technique is AES(Advanced Encryption Standard), but any other secure type of secureencryption can be utilized.

In one embodiment, the alert information 61 and time synchronizationinformation 62 are transmitted to all of the user devices 21-26simultaneously, or substantially simultaneously. In an alternateembodiment, such information is transmitted to the various user devices21-26 at different times. The latter approach is particularly preferredif latency times are expected to vary in an amount that exceeds thedesired tolerance in terms of how closely in time the individualmessages 96 are desired to be delivered. In such a case, the latencydifferences (e.g., the time differences between when the various devices21-26 actually receive the synchronization information 62) willtranslate directly into synchronization inconsistencies among thevarious devices 21-26. Transmitting at least the synchronizationinformation 62 individually to each user device 21-26 can allow for thelatency to that device to be estimated and accommodated to some extent.

If, for example, the transmission latency is variable and may be largerthan the desired tolerance, an alternate technique may be employed toestimate the latency between the server 12 and the individual devices21-26, thereby allowing correction for such latency. Rather than simplytransmitting a synchronization time, the server 12 might first send outone or more probe packets to a subject user device 21, with the clientapplication 80 having been configured to automatically transmit aresponse packet, resulting in a kind of pinging of the subject userdevice 21. Then, assuming that transmission latency is symmetric, theserver 12 need only divide the round-trip latency (or the averageround-trip latency if more than one packet was sent) by two and thenadjust the transmitted synchronization time 62 (e.g., by simply addingsuch quantity) in order to compensate for the expected one-way latency.

Alternatively, any other technique may be used to estimate and adjustfor expectant latency. Also, in certain cases transmitting thesynchronization time 62 separately from the alert information 61 mightbe useful in reducing latency time, particularly where the alertinformation is voluminous relative to transmission bandwidth.

The construction of the alert information 61 typically is relativelystraightforward. A user or a separate automated process supplies server12 with one or more messages 96 that are to be distributed to aspecified group of user devices 21-26 for delivery at one or morespecified delivery times 95. The list of devices 21-26 may be generatedby reference to user preference information indicating which devices areintended to be active at the scheduled delivery times. Such alertinformation 61 may then be delivered (preferably in encrypted form) atany time prior to the earliest specified delivery time 95.

It is noted that step 100 is shown differently than the other processsteps illustrated in FIG. 5. This is because step 100 generally can beperformed at any time during the overall process, e.g., whenever server12 has a new alert 61 to be pushed out. In addition, step 100 preferablyalso as performed upon request either by the server 12 or by thealert-based client 80 running on the user device 21, e.g., in order tocheck for any clock tampering in an attempt to have the messagedelivered early.

Thus, step 100 generally stands outside of the normal process flow,although it preferably is initiated from the sleep or background mode(as described below) under normal circumstances. Nevertheless, step 100preferably is executed as the first step of the present process in orderto achieve an initial time synchronization and download of alertinformation 61.

Next, in step 102 client 80 waits until it is time to check thereal-time clock 86. At the outset, it is noted that the presentembodiment contemplates a “sleep” or “background” mode in which client80 performs minimal processing. One of the functions that preferably isperformed by client 80 during the sleep mode is to periodically checkthe real-time clock 86 in order to determine whether it is time todeliver a message and to confirm accuracy. The wait in this step 102preferably is equal to a fixed number of the clock cycles generated bydevice clock 85.

In this regard, the counting of clock cycles can be performed insoftware. Alternatively, to avoid unnecessary processor use, a simplehardware counter can be used, e.g., one which generates an interruptsignal when the desired count has been reached. In the preferredembodiments, client 80 checks a real-time clock 86 approximately everyfive minutes.

In step 104, client 80 reads the current value of the real-time clock 86and checks for any variances or potential tampering. For the reasonsindicated elsewhere in this disclosure, there often may be significantincentives to learning certain information (e.g., contest questions orfinancial news) prior to the intended delivery time. Accordingly, thepresent invention preferably uses a number of measures to detect andcorrect tampering and normally occurring time discrepancies.

As indicated above, client 80 preferably has access to at least threedifferent time indicators. The first one, the synchronization time 62provided by server 12 generally will be the most accurate, but the leastfrequently updated. The second, the set of periodic clock-check signalsbased on the device clock 85, does not provide absolute time, butprovides an indication of time-interval durations. The third, thereal-time clock 86 provides the most current indication of absolutetime, but that measurement might be out of sync with the clockmaintained by server 12 and frequently will correspond to a differenttime zone. In addition, at least the second and third sourcespotentially are subject to user manipulation. In order to maintaintime-synchronization integrity, in this step 104 client application 80preferably looks for any anomaly between the three sources, whethermanifested as a constant bias, a steady drift or a sudden change.

For example, if the real-time clock 86 indicates a jump in its statedtime between two adjacent check signals, and such jump is sufficientlydifferent from the expected time interval (or even a movement backward),then a tamper condition might be declared. Alternatively, if thedifference is not too far out of specification, then the condition mightbe monitored further (e.g., during the next couple of clock checkpoints)to determine whether the real-time clock 86 of the user device 21 issimply running excessively faster or slower than it should be (e.g.,outside of a specified tolerance). Of course, such a situation alsocould be a result of a more subtle attempt to manipulate the time statedby real-time clock 86. In any event, preferably at a minimum eachmessage-delivery time 95 (or, alternatively, an internal clockcorrection) is adjusted to account for any detected difference.

In step 106, a determination is made as to whether a reset is desired.Such situations can include, e.g., either (i) where the differencebetween what the real-time clock 86 says and what would be expected byvirtue of the periodic check signals based on the device clock 85 isexcessive; or (ii) where the applicable tolerances in the device clock85 and the real-time clock 86 make it difficult to establish which ismost representative of the correct time. In addition, or instead, areset determination can be made arbitrarily, at fixed time intervals, orrandomly, in an attempt to identify more elaborate tampering schemes.

If such a determination is made in this step 106, then processingreturns to step 100 in order to request a new time synchronizationsignal 62 (if such on-demand requests are supported in the applicableembodiment) or simply wait for the next scheduled time synchronizationsignal 62 from server 12 (disabling the applicable user device from thealert system until such synchronization occurs). If a reset is notrequired (e.g., values are within tolerances and/or a determinationotherwise is made that the discrepancies appropriately can be handled byan adjustment), then processing simply proceeds to step 108.

Although not shown in FIG. 5, an affirmative determination of tamperingpreferably causes client application 80 to notify server 12 anddisqualifies the corresponding user from participating in any furthersystem alerts. At the same time, in certain cases the time stated byreal-time clock 86 will be significantly different than the actual timewithout any intentional tampering. Such a condition might occur, forexample, where the device 21 has been reset and does not have aconnection to its wireless carrier, so its real-time clock 86 might bereset to an arbitrary or default time (e.g., 12:00 p.m.). The logic fordeclaring a tamper condition preferably checks for and takes intoaccount all such conditions or, at the very least, allows a certainnumber of unexplained discrepancies before declaring a tamper condition.

In the embodiment discussed above, client application 80 maintains atime offset figure indicating the difference in time between real-timeclock 86 and the clock maintained by server 12. Equivalently,application 80 could maintain its own internal real-time clock, e.g.,using input from all of the three sources indicated above.

In step 108, a determination is made as to whether it is time for thedevice 21 to wake up from its sleep mode. An affirmative determinationin this regard preferably is made if a message is scheduled to bedelivered within a specified amount of time (e.g., within 2-10 seconds)or, in certain cases, prior to the next clock-check signal or within aspecified margin after it. If the determination is negative, thenprocessing returns to step 102 to await the next clock-check signal. Ifpositive, then processing proceeds to step 110.

In step 110, any of a variety of different types of processing may beperformed. Initially, client application 80 preferably brings forward atleast some portion of its user interface (preferably overriding anyconflicting user interfaces). Generally speaking, the first goal of theuser interface in this instance is to capture the user's attention.Accordingly, it is preferable to include some warning signal indicatingthat a message is about to be delivered. Such a signal preferablycomprises an audio alarm, but also could include vibration or othertactile sensations, or even visual cues. The 2-10 seconds mentionedabove in connection with step 108 is intended primarily to accommodatesuch a warning signal (as well as to make the other preparationsrequired for delivering the message on schedule). It is noted that thewarning signal is particularly important, and preferably is somewhatlonger, in embodiments where the time that the message is to bedelivered is not known in advance.

Ordinarily, the user interface also will include some visual displayelements, such as a text message or a logo. However, in certain casesall messages are provided entirely by sound (e.g., using synthesized orsampled speech for devices with a small or nonexistent display), or evenentirely by vibration or other tactile sensation (e.g., for the visuallyimpaired).

Also, in certain embodiments of the invention the warning signal isaccompanied by an opt-out or opt-in message and corresponding period oftime during which the user 31-35 can elect to receive the message orelect not to receive the message (depending upon the selected defaultsetting). An opt-in system generally is preferred, particularly wherethe users 31-35 are only permitted to receive a limited number ofmessages, where they are required to pay for each message receivedand/or where the messages are sensitive and therefore should not be seenby others.

Then, preferably just before the delivery time 95, assuming the user hasopted to receive the message 96, the message 96 is decrypted anddelivered to the user 31-35. The net effect of multiple user devices21-26 implementing similar client applications 80 is that all of theusers 31-35 will receive the message at substantially the same time. Asused herein, the expression, “substantially the same time” and similarexpressions with respect to delivery of a message are intended to meanclose enough in time such that, ordinarily (e.g., assuming a properlyfunctioning system and no inappropriate tampering), recipients generallywill not be significantly advantaged by virtue of having received themessage earlier or disadvantaged by receiving the message late. For mostembodiments contemplated hereunder, the term will correspond todistribution to all recipients within a time window having a maximumduration of approximately 1-3 seconds.

In addition to simply providing a message 96, certain embodiments of theinvention provide functionality for allowing the users 31-35 to respondto the message 96. More preferably, such embodiments display a responseinterface (e.g., one or more clickable or otherwise selectable buttons,objects that can be dragged and/or a field for entering text) on thesame user interface as that on which the message 96 is displayed.Depending upon the particular embodiment, as well as thetime-sensitivity of the response, the response information preferablyeither is immediately transmitted to the server 12 or else is saved intomemory/storage 83 (e.g., in encrypted form) for later transmission toserver 12.

Upon completion of step 110, processing returns to step 102 in order tobegin waiting for the next message delivery.

Although the foregoing technology is discussed within the context ofsimultaneous delivery of a message to multiple individuals, its use isnot so limited. Rather, as should be readily apparent, the foregoingtechnology also can be used for any time-controlled disclosure ofinformation, even where the recipients are receiving it at differentscheduled times. Similarly, the foregoing technology is not limited todisclosures to natural persons; in addition, it can be used, e.g., fortime-controlled release of information to an automated process.Exemplary uses in this latter respect include electronic funds transfersand electronic payment systems.

The foregoing discussion concerns a particular technique forsubstantially simultaneous delivery of a message to a number ofgeographically dispersed recipients. The following two sections describesystems and methods that use such substantially simultaneous delivery ofa message. While the approaches described above for achieving thedesired substantially simultaneous delivery presently are preferred, thesystems and methods described below also may be implemented using any ofa variety of other approaches.

For example, where latency is not a significant factor in relation tothe required time frame for delivering a message to the recipients, adirect broadcast of such information can be used. Alternatively, in suchsituations the message itself can be transmitted in advance (e.g., inencrypted form) and only a release signal broadcast by the server 12 (orany other device) when it is time for delivering the message. Stillfurther, a broadcast message can be used simply to wake up a clientapplication on each of one or more user devices; thereafter, acommunication channel is opened between each such user device and theserver 12, or even among all (or any subset) of such user devices and/orthe server 12.

In an alternate embodiment, a different form of push technology is used.For example, a SMS message can be used to “wake up” each clientapplication 80, with the server 12 then receiving confirmation ofreceipt of that SMS.

In another embodiment, preprogrammed alerts pop up on the user's device21-26 (e.g., using the device's timer) and invite the user 31-35 toclick a button to retrieve a message. One click opens direct (e.g.,HTTP) access to the server 12 to retrieve the desired content.

In a still further embodiment, the subject content is broadcast in realtime to all users 31-35. Such users 31-35 then respond via broadband.

Substantially Simultaneous Intermittent Contest.

FIG. 6 is a flow diagram illustrating a process for conducting a contestaccording to a representative embodiment of the present invention.Generally speaking, the contest according to FIG. 6 is playedsubstantially simultaneously by a number of geographically dispersedplayers at intermittent points in time. Each player participates byusing a (typically network-accessible) device, which may include, e.g.,an Internet-accessible computer, a wireless telephone or a wirelesspersonal digital assistant (PDA), as shown in FIG. 1. It is noted thatif a technology platform according to the preferred embodiments of thepreceding section is used, then it is not necessary for a player'sdevice to be actually connected to a network at the particular momentsthat active play occurs. Such technology currently is preferred forimplementing the present contest, with the contest's problems being thedelivered messages, the player devices corresponding to user devices21-26, and the contest server corresponding to server 12. Accordingly,for ease of explanation, the following discussion assumes such animplementation. However, such references are exemplary only.

Preferably, the contest is played over an extended period of time, suchas anywhere from several days to a month, or even longer. As discussedin more detail below, the contest involves a number of problems, whichmay include multiple-choice or other types of questions. Preferably,each problem is made available to all of the players at substantiallythe same time, and multiple problems are made available each day of thecontest. In order to address the situation that everyone will notnecessarily be able to play at the same time, more problems preferablyare made available than the number of problems that each player ispermitted to respond to, under the rules of the contest.

Initially, upon the beginning of the contest there is a period ofwaiting 131 for the first problem to be delivered. In the preferredembodiments of the invention, neither the problems nor the times atwhich they are to be delivered are known to the players in advance. Fromthe players' perspectives, the problems preferably are delivered atrandom times during the day, or during some specified window of timeduring the day. When that window occurs preferably depends upon the timezones in which the players are expected to be located. In alternateembodiments of the invention, the particular times, or at least some ofthe times, when the problems are delivered are known in advance by someor all of the players.

A feature of the present contest is that problems are delivered atintermittent times over an extended period of time. For example, theintervals between problems typically will be at least 30 minutes andoften will be 1-2 hours or even longer, thereby contributing to therandomness of the play. More generally, the median time between deliveryof problems preferably is at least 30 minutes, 60 minutes or two hours.In addition, the contest typically will go on for at least three days, aweek, two weeks, a month or even longer. In the preferred embodiment,each contest is one month long with three or four problems each day(potentially excluding certain weekend days and/or holidays), but withthe players allowed to respond to only one problem each day.

In any event, shortly before a problem is scheduled to be delivered, instep 132 a user interface is provided to all of the players via theplayers' devices. In the preferred embodiments, the user interfacepreferably includes an alert signal which, in turn, preferably includesan audio component, such as a contest-specific ring tone. It is notedthat the exact timing of the alert signal (if provided) generally is notas sensitive as delivery of the actual problem, provided that thevarious players receive roughly the same amount (or even some minimumamount) of advance warning.

At the same time, the user interface preferably queries whether theplayer wants to respond to this problem or to pass on it. An exemplaryuser interface 170 is illustrated in FIG. 7. As shown, interface 170includes a message 171 notifying the player that a new problem is aboutto be delivered and asking whether the player wants to participate inthe problem. A pair of radio buttons 173 allows the player to designatehis or her choice, with a timer 175 indicating the remaining time untilthe default option (or the currently selected option if the player hashighlighted the other option) is selected. In the preferred embodiments,the default (which occurs if no response is given by the player) is toassume that the player is passing on the problem (as indicated in FIG.7). In a representative embodiment, the timer 175 starts atapproximately 4-7 seconds and counts down.

Thus, referring back to FIG. 6, in step 134 the players who will beparticipating in the present problem are identified (e.g., all of thosewho have opted to receive the problem). In the preferred embodiments,the players do not get any information about the problem, or at least donot obtain the problem itself, before deciding whether to participate.In alternate embodiments, the players may be given some limitedinformation about the problem along with the alert, such as the generalcategory to which the problem pertains. As a result, in such alternateembodiments the players can decide whether to participate based onfactors other than mere convenience (e.g., their comfort level with thegeneral category).

In still further embodiments, the players either do not have any optionas to whether they participate, or at least they are not penalized ifthey respond incorrectly so there is no disincentive to participating.In such embodiments, step 134 generally can be omitted on the assumptionthat all of the players can be deemed to be participants, irrespectiveof whether or not they actually do participate. In a variation on thisembodiment, step 132 also is omitted, so that the players get no advancewarning about when a problem is going to be delivered.

In any event, the set of participants for the current problem preferablyexclude the players who already have answered their maximum allottedproblems for the current period of time (e.g., their one problem for theday). In this regard, the preferred implementation is for anywherebetween 2-8 problems to be presented each day, with each player allowedto answer no more than 1-5 (but preferably always strictly less than thetotal number of problems presented). More preferably, 3-4 problems areprovided each day, with each player allowed to answer not more than 1 ofthem.

It is noted that the excluded participants also may be excluded fromstep 132, thereby sparing them an unnecessary alert. Also, in alternateembodiments the problem may be provided to a player at the same time asthe participating players even if the subject player already hasanswered his or her maximum allotted problems or otherwise has optedout; however, this preferably would be for enjoyment purposes only andany response (if permitted) preferably would not count toward thecompetition. More preferably, however, a problem is not provided tonon-participating players until after the problem has been completed bythe participating players.

In step 137, the problem is presented substantially simultaneously toall of the participating players. In the present embodiment,participating players are required to answer an ordinary problem(special problems are discussed below) within 30 seconds, or else arescored as getting the problem incorrect. For that reason, and in orderto prevent any unfair advantages, the problem preferably is presentedwithin a 3-second window to all or substantially all of theparticipating players under normal circumstances. Of course, playerdevice failures and other physical limitations at least sometimes willpreclude delivery within such a 3-second window to 100% of the playerdevices.

The problems can involve any type of problem (e.g., knowledge-based orskill-based). However, it presently is anticipated that the mostcommonly used problem will be a question, typically a multiple-choicequestion.

An exemplary user interface 190 providing such a problem is illustratedin FIG. 8. As shown, user interface 190 includes a multiple-choicequestion 191, a plurality of potential answers 193, and a count-downtimer 195 which indicates the time remaining in which to provide aresponse. Because a timer internal to application 80 preferably is used,the participant can be given the full response time (e.g., 30 seconds)from the time that the problem initially is delivered (or displayed),even if there are slight differences (e.g., a second or two) among thevarious player devices as to when the problem is delivered in absolutetime.

The potential answers 193 preferably function as input interfaceelements (radio buttons in this case), allowing the player to responddirectly and quickly within the same user interface 190, by simplydesignating the desired response 193. Once such a response is designatedand then selected (or entered), the problem is over from the currentplayer's perspective.

A number of other types of problems may be provided. For example, ratherthan a multiple-choice question, the problem could be a question thatrequires a textual and/or numeric response (e.g., entered through thekeypad of a wireless telephone).

Also, irrespective of the form of the expected answer, the question caninvolve additional media beyond a merely textual question. For example,the participants might be asked to: (i) identify an individual within aphotograph or video segment, (ii) identify the next three notes, or thenext bar, following a segment of a song that is played for theparticipants, (iii) count the number of specified items in a particularphotograph, or (iv) identify which of three movie-clip-and-soundtrackcombinations do not go together. Still further, the problem might bemore in the nature of a puzzle or even a video game, requiring onscreenmanipulations by the participants.

Still further, the problem might involve external events and/or mediaoutside the four corners of the player's devices 21-26. Preferably, suchproblems are special problems that are allotted additional time tocomplete. In one example, the players are directed to find an answer oran item on the Internet. More elaborate problems can involve a sort ofvirtual scavenger hunt, in which players move from one web site toanother searching for the next clue until the answer is found or untiltime expires.

In any event, in step 139 the answers are received, typically by theindividual player devices themselves in the first instance and theneither immediately or subsequently transmitted to the contest server(e.g., server 12). As noted below, in certain cases the response timealso will be transmitted to the server; in others, the player devicesmerely indicate whether the response was received within the allottedperiod of time. In the preferred embodiments, the player devices encryptthe response information before storing it or transmitting it to thecontest server.

In step 141, the players' responses are scored. This step can beperformed either at the player's device 21-26 itself or, aftertransmission, by the server 12, with the resulting score simply obtainedlater (e.g., via the player's device 21-26). In the preferredembodiment, each correct response that was submitted within the requiredtimeframe (e.g., within 30 seconds after the problem was delivered) isawarded a fixed number of points and each incorrect response is assigneda negative point value (e.g., the negative of the point value for acorrect response). However, in alternate embodiments different scoringmechanisms are applied. For example, in certain cases no penalty isattributed to an incorrect response. In other cases, the point award fora correct response is a function of how quickly the participant providedthe response (in which case the participant's response time preferablyis transmitted to the server, if that is where scoring occurs, alongwith the response itself). In other cases, different point levels areassigned for different levels of performance in connection with theproblem (e.g., different point of values for completing 80% of ascavenger hunt and for completing 90% of the same scavenger hunt, withina fixed timeframe).

Next, in step 143 a determination is made as to whether the currentproblem was the last one for the contest. If not, then processingreturns to step 131 to await the next problem. If so, then processingproceeds to step 144.

In step 144, the contest is concluded and the winners (if any) areidentified based on total number of points accumulated. In this regard,a contest according to the present invention may be conducted as atournament with winners (e.g., first, second, third place and/or similarrankings in various subcategories). Alternatively, it may be conductedsimply for the sake of accumulating points, e.g., which then are tradedfor products or services.

In the contests of the present invention, different problems can havedifferent associated point values. For example, the longer, moredifficult or otherwise more involved problems preferably have higherpoint values than the shorter or easier ones. In the preferredembodiments, there are a relatively large number of regular problems(e.g., having a 30-second maximum response time and a standard pointvalue) in just a few higher-value, potentially more involved problems.In certain embodiments, multiple problems (e.g., standard, difficult andextreme, having progressively higher point values) are available at aparticular delivery time and the individual players can select which onethey want to receive. In such cases, preferably all of the problems aredownloaded prior to the delivery time but, for each player, only theselected problem is actually delivered to that player.

Various aspects of the foregoing contest can work together to generate alevel of excitement and novelty that do not exist with conventionalgames or contests. First, as noted above, the contest is notgeographically limited (subject, perhaps, to any practical problems thatmight arise in attempting to conduct the contest across too many timezones). Second, the contest preferably is played substantiallysimultaneously by all of the participants, so that in a reasonably largecrowd several people might receive the alert and begin play, making thepresent contest more of a social event than typically is the case withconventional games or contests that are played on a personal device. Inaddition, when the times that the problems are to be delivered are notknown in advance, an even heightened level of excitement, spontaneityand social connectedness often can occur.

The foregoing discussion focuses on the actual conduct of the contest.In between active playing times, a significant amount of additionalactivity can occur. For example, the individual players preferably havethe ability to: check their point totals; check rankings or standings;view detailed statistics and even photographs of the leaders; viewanswers to, and/or strategies for approaching, previous problems; reviewperformance statistics; generate customized reports regarding howindividual players performed with respect to specified criteria; browseresults from other contests; register for additional contests; and spendthe points that they have accumulated. A number of the foregoing itemscan be particularly important when “powering” is involved, as discussedin the following paragraphs.

In this regard, a significant number of variations on the generalcontest structure described above are possible. One novel variation isthe ability for individual players to “power” with at least one otherplayer. More preferably, each player has the ability to power with oneother player, of his or her own choosing, at a time. In such a case, the“powering player” (the one who makes the selection) is awarded pointsbased on the points earned by the player with whom he or she powered(the “leader”) and vice versa. Thus, by powering with a very goodplayer, an individual can significantly boost his or her points.Conversely, if a player can get a large number of other players to powerwith him or her, his or her own point total can be significantlyenlarged. As a result, a leader's point total typically will depend notonly on how successful he or she is at responding to problems, but alsohow successful he or she is in attracting others to power with him orher. Preferably, the powering player cannot result in a net loss ofpoints to the leader (even in embodiments in which penalties areassessed against the responding player for incorrect responses), butinstead only adds any net point gain earned during the poweringrelationship. On the other hand, in the preferred embodiments theleader's both positive and negative point earnings preferably also areattributed to the players who have powered with that leader (although inthe preferred embodiments, any player's point score can never fall belowzero).

In the preferred embodiments, the powering player can also derive otherbenefits by powering with good leaders. For example, in a tournamentcontest a powering player preferably is permitted to continue playing solong as the leader remains in the tournament, even if the poweringplayer would not have qualified for continued play by himself orherself.

This paragraph describes the particular details of powering according tothe preferred embodiment of the present invention. In this embodiment,three different kinds of points are contemplated, referred to as:“Dotz”, “PowerUp points” and “game points”. At the beginning of eachmonth, in exchange for the monthly fee for participating in the contest,5,000 Dotz are deposited into each player's account, and any negativebalance from the previous month (if permitted) is zeroed out, so thateach player has a minimum of 5,000 Dotz. In addition to earning Dotzbased on their own performance, each player may power with one otherplayer at a time, essentially binding all of his or her Dotz to thatother player for a desired period of time. Irrespective of powering,Dotz are awarded to or subtracted from the player based on theindividual player's own correct and incorrect responses and based on thenumber of Dotz assigned to each individual problem. In addition, if theplayer has powered, the same number of Dotz is added or subtracted basedon the leader's answer to the problem. The player can pull back his orher Dotz from the leader at any time or switch them to another leader,although the player cannot leave and then return to the same leaderduring a contest. The leader, in turn, receives a number of PowerUppoints equal to the total number of Dotz earned by all players whocurrently are powered with the leader, but does not lose PowerUp pointswhen a powering player answers incorrectly (or at least does not incur anet loss due to any given powering player as a result of the poweringrelationship; in certain sub-embodiments, PowerUp points contributed bya powering player can later be lost by incorrect responses given by thatsame powering player). A player can power up his or her Dotz with aleader, but not any PowerUp points that he or she has earned (as aresult of other players powering up with him or her). Each player's gamescore is equal to that player's Dotz plus his or her PowerUp points. Atthe end of each contest, additional Dotz are awarded to each player on asliding scale based on overall rank in the contest and/or the absolutenumber of game points that particular player has, and the total numberof Dotz can be exchanged for prizes (e.g., products or services). Anexample of such a sliding scale 200 is shown in FIG. 9, which includesrows for final game score 202, number of players 204 and Dotz earned 205based on game score. In the present example, Dotz are earned based onrank: the player with the largest number of game points gets 1,000,000Dotz, the next five highest get 500,000, the next 10 highest get100,000, and so on, with the game score cut-offs 202 being determinedonly upon completion of the contest. In another embodiment, the gamescore cut-offs 202 are fixed and the number of players who fall withineach range varies from contest to contest. Alternatively, any otherconversion technique using any combination of overall rank and totalnumber of game points may be used.

The ability to power, as discussed above, often can transform whatotherwise would be a solitary or anonymous endeavor into a group or teamactivity, in which individual players are incentivize to track theperformance of, and root for, other players. In the preferredembodiments of the invention, players have flexibility to switch to adifferent leader (thereby providing incentive to monitor others'performance), but restrictions are applied so that the powering playersare forced to carefully consider any such changes. More preferably,during a given contest a player is not allowed to power with the sameleader twice, meaning that once a powering player leaves a leader, he orshe cannot go back during the same contest.

Variations on the powering concept also are possible. For example, thepowering players might receive only a specified percentage (or someother function) of the points earned by the leader and/or vice versa.Alternatively, or in addition, a player might incur a cost for powering(e.g., a loss of 50% of the points he or she otherwise would earn,meaning that it would only make sense to power if one thought that theleader would perform better than the powering player). Still further, inembodiments in which the powering player can in fact harm the leader,the leader preferably has some control over which players power withthem.

However, despite the variations, the general concept of powering is thatan individual player has the ability to associate with one or more otherplayers for a desired period of time and then flexibly switchassociations as desired, potentially benefiting from the successes ofthe associated players (and in certain embodiments potentially beingharmed by the losses of the associated players). Another preferredfeature of powering is that individual players have an incentive toattract other players to power with them.

Also, rather than (or in addition to) powering, contests according tothe present invention can include flexibly constituted teams. In onesuch embodiment, the performance of a team as a whole affects the pointaccumulation of its individual members, for any periods of time thatsuch members are in fact affiliated with the team. While similar in somerespects to powering, such a team approach lacks a direct one-to-onerelationship between individual players and a leader, insteadpotentially leading to dynamics in which small ad hoc clusters ofindividuals are more likely to form.

In either the case of powering or teams, in certain embodiments thecontest includes rules regarding the structure of the resulting groupsand how individual players within the groups accumulate points. Forexample, the rules might create a multi-level point-earning structurewithin each group such that the leader earns the highest percentage, thenext level down (perhaps limited to a fixed number of people) the nexthighest percentage, and so on. Such a structure could lead to intensenegotiations about who is assigned to what level, with the risk that anyindividual player might defect to a different group (or leader) if he orshe feels a better deal can be obtained.

In still further embodiments, by also structuring point awards morealong group lines, incentives easily can be created for each group toattempt to ensure that each relevant area of knowledge or expertise isadequately covered, or even that each level within the group isadequately diverse in this regard.

The present invention contemplates contests that test the players acrosswide ranges of knowledge and skill, and as well as special-interestcontests, such as contests targeted toward any specific area ofinterest, knowledge or skill (e.g., sports or entertainment), or anyparticular demographic (e.g., children, tweens or teens). As indicatedabove, the contest can be implemented as a competition with identifiedwinners and potentially bonus points or prizes at the end (typicallyreferred to as a tournament), as a time-limited opportunity toaccumulate points which can be exchanged for products or services, or asa combination of both. In one example, at the end of the contest onlythe individual players having the highest point totals, together withany players who have powered with them, are invited to participate in anelimination tournament, e.g., with the powering players remaining in thetournament as long as their leader does.

For purposes of any tournament elimination or any similar aspect ofcompetition, the rules can be constructed such that at any stage onlythe player's earned points are considered (excluding any poweredpoints), all of the player's points are considered (including thepowered points), or any (e.g., weighted) combination of the two isconsidered.

Additional Systems and Methods Involving Substantially SimultaneousDelivery.

The technology described above for facilitating simultaneous delivery ofmessages can be used for other purposes besides contests havingsimultaneous play. One category of such uses is any situation wheresimultaneous communication is desired or necessary. While broadcastmedia traditionally have been used for this purpose in the past,broadcast media are inherently limited in that the audience must haveaccess to the media and be tuned in at the time an announcement is made.Also, broadcast media having low latency variability (such as televisionor cable broadcasts) generally are not suitable for small-scale releasesof information. As noted above, the preferred embodiments of the presentinvention do not require connectivity at the time a message isdelivered, and can permit delivery of a message using a wide range ofdifferent devices. Accordingly, a recipient can be more certain that heor she will get an important message at the same time everyone elsedoes. Situations where such substantially simultaneous communicationsare important include announcement of certain economic and financialnews.

Another category of use is where some coordinated activity is desired.As noted above, according to one feature of the present invention, theuser devices for all participants wake up or activate at substantiallythe same time, prompting all such participants into action. This featurecan be useful, for example, as an alert that an item being monitored onan on-line auction has just entered the last five minutes of theauction. In such a case, although the initial announcement generallywould not require network connectivity, some connectivity typicallywould be required to actually submit a bid.

An example where coordinated shopping activity can be carried outwithout any immediate connectivity is where a product or service is madeavailable for sale to the first purchasers. In such a case, using thepreferred message delivery technology described above, the initialannouncement message is stored in advance on the user's device togetherwith a delivery time. Then, after the message has been delivered, thedevice stores the response and the response time, transmitting suchinformation back to the server at an appropriate moment. After the fact,the server can identify the winning purchasers by simply ranking theresponse times. Note that this embodiment also largely eliminates thelatency problems associated with conventional systems for selling outinventory (e.g., concert tickets) over a very short period of time.

Still further applications of the present technology include: sprinklersystems that can be re-programmed remotely; simultaneous opening oflocks at banks or other establishments; real-time synchronized trafficlight control for efficient traffic flow; updating of electronicbillboard content; control of school exams throughout a state or othergeographic region; simultaneous adjustment of supermarket pricing at alarge number of stores; hotel alarm clocks; simultaneous real-timedownloading of prescribed changes in rates to electric meters or otherutilities, e.g., giving users a financial incentive to consume duringoff-peak hours; controlling or timing other aspects of game playing;medication dispensing control (e.g., timing and schedule updating);real-time polling (e.g., Neilson Television Polling) in order to captureinstantaneous reactions (e.g., with incentives for the participants torespond immediately) or to track changing reactions over time bycapturing reactions at a sequence of points; and in-store promotions(e.g., blasting a promotion to all subscribers to come to the store topurchase any item for a prescribed discount).

Another use of the present technology is in conjunction with broadcastprogramming. In one such embodiment, content related to a broadcastprogram (e.g., television or radio show) is downloaded to the userdevice 21-26 and then is delivered to the corresponding user 31-35 insynchronization with the program. However, the specific messages thatare delivered preferably depend upon selections made by the user 31-35on his or her device 21-26. As a result, an interactive experience canbe created without any special-purpose hardware or any connectivityother than the ability to see the broadcast. In one sub-embodiment, eventhe broadcast has been recorded, with the program recorder/replayer'sclock having been synchronized to the clock of the user device, e.g., inthe manner described above for user device 25. Note that suchembodiments use the present technology for personalized messagedelivery, rather than substantially simultaneous mass delivery of acommon message.

A still further use of this technology is for conducting a real-timeaudience-participation contest over a broadcast medium. According to onesuch example, the broadcaster transmits (e.g., broadcasts) a wake-upsignal to a number of different user devices 21-26. Substantiallysimultaneously, the user devices 21-26 wake up and allow theircorresponding users to begin playing, preferably at the same timeopening up a communication channel with the server 12. It is noted thateither or both of the wake-up signal and the problem to be solved may betransmitted in real-time or transmitted in advance and stored on thecorresponding devices 21-26, as discussed in detail above. In eitherevent, the wake-up signal may be provided to all eligible players oronly to a (e.g., randomly selected) portion of them. In the preferredembodiments, the problem is delivered to all of the audience members(e.g., via television broadcast) at the same time as it is delivered tothe participating players, although preferably only the responses of theparticipating players affect the outcome of the contest. Also, uponwaking up, the user devices 21-26 preferably time the user responseslocally so as to avoid any communication latency discrepancies among thevarious user devices 21-26, with the resulting responses and responsetimes being transmitted back to the server 12. System Environment.

Generally speaking, except where clearly indicated otherwise, all of thesystems, methods and techniques described herein can be practiced withthe use of one or more programmable general-purpose computing devices.Such devices typically will include, for example, at least some of thefollowing components interconnected with each other, e.g., via a commonbus: one or more central processing units (CPUs); read-only memory(ROM); random access memory (RAM); input/output software and circuitryfor interfacing with other devices (e.g., using a hardwired connection,such as a serial port, a parallel port, a USB connection or a firewireconnection, or using a wireless protocol, such as Bluetooth or a 802.11protocol); software and circuitry for connecting to one or more networks(e.g., using a hardwired connection such as an Ethernet card or awireless protocol, such as code division multiple access (CDMA), globalsystem for mobile communications (GSM), Bluetooth, a 802.11 protocol, orany other cellular-based or non-cellular-based system), which networks,in turn, in many embodiments of the invention, connect to the Internetor to any other networks); a display (such as a cathode ray tubedisplay, a liquid crystal display, an organic light-emitting display, apolymeric light-emitting display or any other thin-film display); otheroutput devices (such as one or more speakers, a headphone set and aprinter); one or more input devices (such as a mouse, touchpad, tablet,touch-sensitive display or other pointing device, a keyboard, a keypad,a microphone and a scanner); a mass storage unit (such as a hard diskdrive); a real-time clock; a removable storage read/write device (suchas for reading from and writing to RAM, a magnetic disk, a magnetictape, an opto-magnetic disk, an optical disk, or the like); and a modem(e.g., for sending faxes or for connecting to the Internet or to anyother computer network via a dial-up connection). In operation, theprocess steps to implement the above methods and functionality, to theextent performed by such a general-purpose computer, typically initiallyare stored in mass storage (e.g., the hard disk), are downloaded intoRAM and then are executed by the CPU out of RAM. However, in some casesthe process steps initially are stored in RAM or ROM.

Suitable devices for use in implementing the present invention may beobtained from various vendors. In the various embodiments, differenttypes of devices are used depending upon the size and complexity of thetasks. Suitable devices include mainframe computers, multiprocessorcomputers, workstations, personal computers, and even smaller computerssuch as PDAs, wireless telephones or any other appliance or device,whether stand-alone, hard-wired into a network or wirelessly connectedto a network.

In addition, although general-purpose programmable devices have beendescribed above, in alternate embodiments one or more special-purposeprocessors or computers instead (or in addition) are used. In general,it should be noted that, except as expressly noted otherwise, any of thefunctionality described above can be implemented in software, hardware,firmware or any combination of these, with the particular implementationbeing selected based on known engineering tradeoffs. More specifically,where the functionality described above is implemented in a fixed,predetermined or logical manner, it can be accomplished throughprogramming (e.g., software or firmware), an appropriate arrangement oflogic components (hardware) or any combination of the two, as will bereadily appreciated by those skilled in the art.

It should be understood that the present invention also relates tomachine-readable media on which are stored program instructions forperforming the methods and functionality of this invention. Such mediainclude, by way of example, magnetic disks, magnetic tape, opticallyreadable media such as CD ROMs and DVD ROMs, or semiconductor memorysuch as PCMCIA cards, various types of memory cards, USB memory devices,etc. In each case, the medium may take the form of a portable item suchas a miniature disk drive or a small disk, diskette, cassette,cartridge, card, stick etc., or it may take the form of a relativelylarger or immobile item such as a hard disk drive, ROM or RAM providedin a computer or other device.

The foregoing description primarily emphasizes electronic computers anddevices. However, it should be understood that any other computing orother type of device instead may be used, such as a device utilizing anycombination of electronic, optical, biological and chemical processing.

Additional Considerations.

In certain instances, the foregoing description refers to clicking ordouble-clicking on user-interface buttons, dragging user-interfaceitems, or otherwise entering commands or information via a particularuser-interface mechanism and/or in a particular manner. All of suchreferences are intended to be exemplary only, it being understood thatthe present invention encompasses entry of the corresponding commands orinformation by a user in any other manner using the same or any otheruser-interface mechanism. In addition, or instead, such commands orinformation may be input by an automated (e.g., computer-executed)process.

Several different embodiments of the present invention are describedabove, with each such embodiment described as including certainfeatures. However, it is intended that the features described inconnection with the discussion of any single embodiment are not limitedto that embodiment but may be included and/or arranged in variouscombinations in any of the other embodiments as well, as will beunderstood by those skilled in the art.

Similarly, in the discussion above, functionality sometimes is ascribedto a particular module or component. However, functionality generallymay be redistributed as desired among any different modules orcomponents, in some cases completely obviating the need for a particularcomponent or module and/or requiring the addition of new components ormodules. The precise distribution of functionality preferably is madeaccording to known engineering tradeoffs, with reference to the specificembodiment of the invention, as will be understood by those skilled inthe art.

Thus, although the present invention has been described in detail withregard to the exemplary embodiments thereof and accompanying drawings,it should be apparent to those skilled in the art that variousadaptations and modifications of the present invention may beaccomplished without departing from the spirit and the scope of theinvention. Accordingly, the invention is not limited to the preciseembodiments shown in the drawings and described above. Rather, it isintended that all such variations not departing from the spirit of theinvention be considered as within the scope thereof as limited solely bythe claims appended hereto.

1. A method for implementing a simultaneous, but intermittently played,contest, comprising: (a) delivering a problem substantiallysimultaneously to geographically dispersed players, the problem beingidentical for all players; (b) receiving responses to the problem fromthe players and measuring response times corresponding to the responses;(c) determining scores for the players that are based on the responsesand corresponding response times; and (d) repeating steps (a)-(c) aplurality of times, with a median time interval between delivery ofconsecutive problems being at least 30 minutes, and with an aggregatescore being maintained for each of the players.
 2. A method according toclaim 1, wherein there are at least 100 players.
 3. A method accordingto claim 1, wherein for each of at least a majority of the players, theproblem is delivered, the response is input and the response time ismeasured on a same user device.
 4. A method according to claim 3,further comprising a step of downloading the problems into the userdevices in advance, via a publicly accessible network.
 5. A methodaccording to claim 1, further comprising a step of permitting theplayers to decide whether or not to participate in a current problem,wherein only the players who participate in the current problem arescored with respect to the current problem.
 6. A method according toclaim 5, wherein more problems are available than the players arepermitted to answer, so that the players have flexibility regarding whenthey participate.
 7. A method according to claim 1, further comprisingsteps of: (e) allowing the players to voluntarily associate with atleast one other player; and (f) while and only while an associationexists between a first player and a second player, providing the firstplayer with points that are based directly on a number of points earnedby the second player.
 8. A method according to claim 7, wherein thefirst player has an ability to transfer the association from the secondplayer to a third player, in which case the first player ceases toreceive points based on points earned by the second player and begins toreceive points that are based directly on a number of points earned bythe third player.
 9. A method according to claim 1, wherein the playersmust answer the problem within a specified period of time after theproblem is delivered in order to obtain credit for answering correctly.10. A method according to claim 9, wherein the specified period of timeis not more than 90 seconds.
 11. A method according to claim 1, whereinopportunities to answer the problems are provided to the players attimes that are not known in advance to the players.
 12. A methodaccording to claim 1, wherein a correct response to a given problem isawarded a number of points that depends upon how quickly the correctresponse was submitted after the given problem was delivered.
 13. Amethod according to claim 1, wherein said steps (a)-(c) are repeated ona daily basis over a period of at least 5 days.
 14. A system forimplementing a simultaneous, but intermittently played, contest,comprising: (a) means for delivering a problem substantiallysimultaneously to geographically dispersed players, the problem beingidentical for all players; (b) means for receiving responses to theproblem from the players and measuring response times corresponding tothe responses; (c) means for determining scores for the players that arebased on the responses and corresponding response times; and (d) meansfor repeating execution of means (a)-(c) a plurality of times, with amedian time interval between delivery of consecutive problems being atleast 30 minutes, and with an aggregate score being maintained for eachof the players.
 15. A system according to claim 14, wherein there are atleast 100 players.
 16. A system according to claim 14, wherein for eachof at least a majority of the players, the problem is delivered, theresponse is input and the response time is measured on a same userdevice.
 17. A system according to claim 16, further comprising means fordownloading the problems into the user devices in advance, via apublicly accessible network.
 18. A system according to claim 14, furthercomprising: (d) means for allowing the players to voluntarily associatewith at least one other player and while, and only while, an associationexists between a first player and a second player, providing the firstplayer with points that are based directly on a number of points earnedby the second player.
 19. A system according to claim 18, wherein thefirst player has an ability to transfer the association from the secondplayer to a third player, in which case the first player ceases toreceive points based on points earned by the second player and begins toreceive points that are based directly on a number of points earned bythe third player.
 20. A system according to claim 14, whereinopportunities to answer the problems are provided to the players attimes that are not known in advance to the players.